2025년이 4개월 좀 넘게 남은 시점이지만, 올해 경험했던 내용들 중에서, 어떤 성장이 있었는지, 그 과정에서 무엇을 느꼈는지를 가볍게 정리해봤다.

Mongo-Java-Driver 오픈소스 기여

Kotlin으로 구현되어있는 서버에서는 기존에 KMongo를 사용하고 있었다. 그러나 atlas의 vector search 기능이 필요해졌고, KMongo에서는 aggregate 내부에서 $vectorSearch 를 사용할 수 없었기에, 해당 기능을 제공하는 official MongoDB Kotlin driver를 사용하도록 migration이 필요했다. 다만, 이 과정은 그렇게 순조롭지는 못했다. KMongo에서는 jackson 을 사용하여 data class에 대해 직렬화/비직렬화를 할 수 있도록 기능을 제공하지만, Kotlin Mongo Driver의 공식 문서에서는 kotlinx.serialization 을 사용하도록 안내가 되어있다. 기존에 프로젝트에서는 camelCase 로 작성되어있는 data class의 필드가 MongoDB로 저장될 때 snake_case 로 변환되도록(db 내용을 kotlin으로 읽어올 때는 반대로) 할 때, jackson의 naming strategy를 사용했었다. 그러나 Kotlin Mongo Driver 쪽에서는 관련한 naming strategy가 없던 상황이었다. Kotlin Mongo Driver가 꼭 필요해서 프로젝트에 사용해야하는 상황이었고, 그에 따라 두가지 선택지가 생겼다.

1. 직접 Kotlin Mongo Driver에서 Custom Codec을 작성한다.
2. Kotlin Mongo Driver에 직접 Naming Strategy가 작동하도록 기여한다.

(그러나 결과적으로는 1번과 2번을 모두 선택하게 되어버렸다.)

1번 방식은 모든 primitive type에 대해 어떤식으로 bson으로 변환할지, bson을 어떻게 data class로 변환할지에 관한 로직을 모두 작성해야했기에 부담이 커서, 최초에는 2번 방식을 선택했다. 그러나 PR Merge가 빠르게 진행되지 않아서(Merge 되기까지 1달이 넘게 걸렸다..!), 1번 방식을 구현하여 프로젝트에 적용하게 되었다.

추후에 나와 같은 방식으로 KMongo를 사용하고 있는 분이 계시다면, Kotlin Mongo Driver로 마이그레이션 하는 과정에서 BsonNamingStrategy.SNAKE_CASE 를 사용하면 좀 더 수월하게 마이그레이션을 진행할 수 있을 것이다.

PR이 리뷰되는 과정에서 생각지도 못한 케이스에 대한 리뷰를 받기도 했었다. Kotlin의 경우에는 변수명이 unicode 캐릭터를 포함할 수 있기 때문에, 정규식으로 작성한 case convert 로직이 러시아어(имяПеременной)와 같은 경우에는 작동하지 않을 수 있다는 내용이었다. 오픈소스 프로젝트에 어떤식으로든 기여 자체를 하는 것은 쉬울 수 있는 것 같다. 오픈소스에 많이 기여할 수록 나의 개발 실력이 좋은 것 처럼 생각하고 있기도 했었다. 그러나 내가 미처 생각하지 못했던 부분에 대한 이야기를 나누는 과정에서 성장이 이루어질 수 있음을 느끼게 됐다.

EKS 환경 설정

PCI-DSS 인증을 위해 동일한 VPC 내에 존재하던 개발 환경과 운영 환경을 별도의 VPC로 마이그레이션을 진행해야했다. Subnet은 분리되어있었지만, 동일한 VPC 내에서는 Subnet이 분리되어있더라도 접근이 가능하다. 이미 생성된 EKS cluster는 VPC 변경이 불가능하므로 새로운 VPC를 생성해야했고, 이 과정에서 IaC 툴로 Pulumi를 사용해보게 되었다. Javascript로 cloud resource를 관리할 수 있어서 빠르게 학습할 수 있었다. 기존 VPC에 있던 RDS나 ElastiCache와 통신을 유지하면서 새로운 VPC로 이전이 진행되어야했는데, 최소한의 downtime을 갖기 위해 새벽 시간에 작업을 했었다. (다행히 안전하게 마이그레이션을 완료할 수 있었다..) 이 과정에서 VPC에 대한 이해도가 정말 많이 자랐고, 안정적인 migration 전략을 고민하게 됐던 시간이었다. cluster 상에서 사용하던 helm chart들이나, devops 관련 세팅들을 새로운 VPC에 하나하나 설치해나가는 과정은 생각보다 굉장히 즐거웠다. 추후 새로운 클러스터를 구성할 일이 있을 때, 자신감을 갖고 진행할 수 있을 것 같다.

LLM 사용 고도화

LangChain / LangGraph / Langfuse 를 사용해보는 경험을 했다. 저렴한 모델을 사용했을 때의 단점을 multi agent 구조를 사용하는 것으로 해결할 수 있었는데, agent들을 호출하는 구조가 복잡해지다보니 이를 LangGraph를 사용함으로써 해결 할 수 있구나,, 하는 생각을 하게 되면서, LangGraph의 등장 배경을 이해하게 되었다.. LLM을 잘 사용하기 위해서는 Prompt를 어떤식으로 작성할지, Structured Output을 어떻게 사용할지를 결정하는게 중요하다. 이 때, LangChain을 사용하면 AI를 잘 사용할 수 있도록 도와준다. LangChain 문서를 보다보면 유용한 팁들을 많이 발견할 수 있다. 사용자와의 대화 기록을 memory에 어떻게 저장할지, 사용자의 요청에 대한 few shot prompt를 dynamic 하게 제공해주는 방법 등에 대해 잘 작성되어있었다. 이 과정에서 Document의 오류를 발견하고 Repository에 기여할 수 있었다. Langfuse와 같은 AI 모니터링 서비스들이 사용하기도 편리하고, 상당히 잘 작동하고 있는 것을 보면서, 기술적으로 한발 앞서가는 제품을 개발하는 사람들이 참 대단하게 느껴졌다.

Claude Code 사용

OpenAI의 pro plan을 구독해서 사용하고 있다가, hallucination이 심해서 신뢰가 안가기 시작했었다. 그래서 IntelliJ의 Junie를 최대한 사용하고 있었는데, 어느순간 돌아보니 gpt는 개발할 때는 거의 사용하지 않게 되었다. Junie가 사용하는 모델이 Sonnet 4 또는 Sonnet 3.7인 것을 보며, 나도 claude로 갈아타야겠다 생각이 들게 되었다. 그렇게 claude를 구독해서 사용한지 1달이 되었는데, 최근에 GPT-5가 나왔다는 소식을 들었다. 사람들의 반응은 되게 다양한 것 같다. Cursor에서 GPT-5를 사용할 수 있다는 기사를 보기도 했는데, AI를 사용해서 product를 만들어내기 참 좋은 시기임을 느낀다. 어떤 도구가 나의 개발을 가장 잘 도울 수 있을지는 아직 잘 모르겠지만, AI 도구를 업무에 잘 활용할 수 있어야겠다는 생각이 든다. 우선, 현재까지는 claude code를 사용해서 만들고 싶은 것들을 잘 만들어가고 있다. 아내와 같이 쓸 중국어 단어장, 아내의 구직을 돕기 위한 크롤러, ECU 홈페이지 개선 등,, 다양한 작업들을 일을 쉬는 기간 동안 진행했는데, 꽤 만족스럽다. 가끔은 AI에게 시키는 것 보다, 내가 직접 하는게 편하기도 하다.(이럴 때 아직은 개발할 때 사람이 필요하구나,, 생각이 든다.) AI에게 일을 명확하게 잘 시키는 능력을 키우는 것도 필요함을 느낀다. (결국 영어도 잘해야하겠다 ㅜ)

앞으로 어떻게 해야할까?

다양한 회사들의 여러번의 과제와 면접을 보면서, 결국 감사하게도 새로운 회사를 만나게 되었다. 어떤 개발자가 좋은 개발자인지 생각하게 된다. 부족함을 인정하고, 나를 아름답게 포장하고 싶은 욕심을 내려놓는게 중요한 것 같다. 이전 회사에서도 많이 노력했지만, 사람들과 소통을 "열심히 & 잘" 하는 사람이 되고 싶다. 지속적인 선행을 실천할 수 있는 힘은, 예수님께서 죄인인 나를 구원해주셨다는 사실을 인정하고, 믿고, 감사하는 것에서 온다는 것을 잊지 말고, 내 안의 반골기질을 죽이며 하루하루를 정말 겸손하게, 말씀따라 살아가자.